The present invention relates to the utilization of a remote application to open a remotely located document. In the preferred embodiment, the present invention opens the document in response to the activation of a hyperlink, selection of a reference, or some other indication by a user that they wish to access a particular document. In this description, the use of a reference or hyperlink in this matter is referred to as an AppLink. The technology for creating and using an AppLink is described in detail in the Ser. No. 09/866,454 priority application. The primary purpose of the Applink technology is to avoid costly, insecure and time-consuming physical distribution of documents, while also avoiding the problems inherent in the the electronic distribution of documents over the Internet.
The AppLink technology utilizes a three-tier application access technology that is known in the prior art. This prior art technology is typified by the remote application access (“RAA”) software solutions provided by Tarantella, Inc. (Santa Cruz, Calif.) and Citrix Systems, Inc. (Fort Lauderdale, Fla.). RAA software solutions generally provide the thin-client software running on the recipient's computer (the first-tier), and RAA server software operating on the second tier. The second-tier RAA server software is capable of launching a server-side software application, running on a server within the third-tier. The software application's user interface is remotely presented to the recipient via the thin-client, providing fully functional access to the third-tier application. The second-tier RAA server software then controls the flow of information (the user inputs and interface) between the first-tier thin-client and applications running on the third-tier servers. To interact with the third-tier application servers, the second-tier RAA server generally utilizes well-known application platform protocols such X Windows, Microsoft's Remote Desktop Protocol (Microsoft, Inc., Redmond, Wash.), and terminal protocols like VT, 3270, and 5250.
The AppLink technology supplements prior art RAA solutions by associating a link or reference with a document, while also associating a set of attributes or properties with that document. With an AppLink, it is not necessary to send a document from one user to another. Instead, only a reference to the document needs to be communicated to the user. The key to the solution is its ability to encapsulate a document and an application into a single hyperlink or other reference, such as a Uniform Resource Locator (URL), that enables assured, ubiquitous access to that document.
When a user selects or “opens” an AppLink, specialized AppLink server software operating on the second-tier locates and retrieves the desired document within server-side storage, launches the appropriate third-tier application software, opens the desired document in the third-tier application, and then ensures delivery of the thin-client user interface to the client. The second-tier AppLink server software is also responsible for ensuring that the user interfaces with the third-tier application software through an isolated account of a type appropriate to the application software (e.g., NIS/LDAP for UNIX/Linux applications or Active Directory for MS Windows applications). The software components that make all of this happen are collectively known as user provisioning.
The AppLink document attributes are generally created when the AppLink itself is created, and are stored as file-specific meta-data. This meta-data can be hidden within the AppLink itself, or can be stored externally (such as in a database) and be referenced by the AppLink. One such property might designate the software application that should open the file (e.g., Microsoft Word for opening a word processing document). This software application can be pre-selected when the AppLink is created. Alternatively, and preferably, the AppLink server can select the software application at access time from among several possible applications. This run-time selection of application programs allows for multiple licensing models. For example, an external, anonymous access may utilize a less expensive/royalty-free application software, while internal, named account users will use more expensive application software that has already been licensed for that user. The selection of an application for a document and a specific user is generally referred to as application provisioning. AppLink attributes may also include an access password required before a user can view the document, permission to print and/or download the document, permission to modify the document and then return changes to the sender, access duration (i.e., to/from dates for valid access), recipient identification requirements, and AppLink sender notification options (e.g., an e-mail indicating access). These attributes provide a simple form of digital rights management.
Within the context of an AppLink, one of the fundamental challenges to overcome is programmatically managing the third-tier productivity application. Without such management, it would be impossible to implement some of the above-described features, such as the digital rights management features that limits the type of activities the user may perform on a particular document. One way to manage or control these productivity applications on the third tier is by managing the launching of the application through a program launcher. Most operating systems (e.g., Microsoft Windows, Sun Solaris) contain shell or application launching programs that do exactly that—they accept commands that start other programs. Unfortunately, program launchers have significant shortcomings when it comes to the control necessary to effectively manage a third-tier productivity application.
One such shortcoming is the assumption that the user has a dedicated user profile on the machine that is running the productivity application. In the case of AppLink, the productivity application's user interface is routinely delivered to a relatively anonymous remote user—outside of the knowledge of the application. Application-specific settings may not be suitable to display the document in the manner intended. For example, the document may be a workflow file that is intended to show modifications by a series of users. Normally, the editing productivity application would be physically installed on the recipient user's machine and, hence, would inherit the user's personal attributes (e.g., display name). Subsequent document changes would normally be able to record the author's display name. Server-side application deployment makes it cumbersome for a Web-based user to personalize an application before its use.
Another shortcoming of existing program launchers is the assumption that the user is physically located at the machine that is running the productivity application. Again, the productivity application's user interface is delivered to the remote user—outside of the knowledge of the application. Programmatically controlling the shutdown of software applications becomes vital when users are remote and are using essentially unmanaged applications (i.e., productivity applications that are document-centric, as opposed to client/server applications that connect to managed resources that are designed to recover from sudden disconnects from the client software). A prolonged network disconnect may suspend the user's session but, ultimately, the program launcher is left with the choice of either leaving server resources allocated forever, or to force a termination of the productivity application without giving the application a chance to save data, complete document processing or to even clean up temporary files.
Furthermore, prior art RAA software such as Tarantella Enterprise 3 allows a single command-line invocation as the only means for interacting with the third-tier application. In other words, once the application session is initiated, the second-tier loses control over the environment, except to terminate the session without warning. That is not to say no communication takes place with the third-tier application software. Remote interface display technologies, such as Microsoft's RDP and the Open Group's X window system, allow for separate virtual channels for carrying device communication and presentation data from the third-tier server (application output), as well as mouse and keyboard data from the client (input data). These channels may be used to provide features that require communications between the client device and a third-tier application running in a Terminal Services or X windows session (e.g. providing client-side printer information to the third-tier server for proper output formatting). Unfortunately, these communications channels run directly between the client device and the third-tier session environment—the second-tier has no access to these channels. Additionally, the communication channel cannot provide access to application-specific functionality, as the application itself is not generally programmed to listen for such data.
Prior art systems also have problems with load balancing. Remotely deployed applications typically run within an array of third-tier servers set aside for this purpose and they often support a relatively large number of remote users. Application provisioning restrictions and/or load balancing considerations will create an environment where one user may be running third-tier applications on more than one third-tier server. Limiting the number of distinct application processes, or remote display sessions, is vital to supporting a large number of users.
Most program launchers will simply invoke the same command using the same steps; that is, to view two MS Word documents, launch Microsoft Word twice with two different document names. Microsoft Windows would normally invoke WINWORD.EXE twice on the third-tier machine. Microsoft Word is designed to only launch one copy of the application and simply present two separate windows containing the respective documents. Clicking on the close-glyph of the first Word window will only close the first document. Repeat the same steps with MS Excel; closing the first document window will close all Excel windows. Performing the same exercise with Microsoft Visio will result in yet another interaction model: multiple documents running within a single application window. Sun StarOffice differs even more, as a single executable implements document functions for all of the standard office formats. These subtle interaction differences create problems when deploying a heterogeneous mix of applications outside of their normal environment (i.e., in the third-tier instead of in a collection of UNIX/Linux and Windows desktops).